This chapter describes bridging features that are available with the Adaptive Source Routing Transparent (ASRT) bridge. The chapter includes the following sections:
The IBM 8371 also supports TCP/IP Host services, which let you configure and monitor a bridge . This option gives you the following capabilities:
When viewed from the bridge's monitoring interface, TCP/IP Host Services is handled as a new protocol having its own configuration and monitoring prompts. These prompts are accessed via the protocol command in talk 6 and talk 5.
For Bridge Management via SNMP, the IBM 8371 supports the management information bases (MIBs) as specified by RFC 1493 and RFC 1525, except for the following MIBs:
Dynamic protocol filtering (DPF) VLANs are based on protocol and subnets, in addition to user-defined traffic types. For each configured vlan, the subset of bridge ports on which traffic for that vlan is received is the forwarding domain of that vlan. Dynamic protocol filtering (DPF) can partition the bridged network into:
DPF monitors traffic on each bridge port and learns the location of traffic matching the configured protocols and subnets. Ports with matching inbound traffic are included in the forwarding domain of the corresponding VLAN.
IP Multicast VLANs restrict IP multicast data to ports in the same IP multicast group and ports attached to multicast devices. IGMP Report frames are used to determine port inclusion in the forwarding domain for a particular IP Multicast VLAN. Also, ports receiving IGMP Query device frames are included in the forwarding domain of all IP Multicast VLANs to insure all IP multicast data is sent to the multicast devices.
The purpose of DPF is to limit the proliferation of frames that are normally forwarded over all active spanning tree ports. DPF dynamically activates filters based upon the traffic on each bridge port. The bridged network can thus be dynamically partitioned into protocol-specific subnetworks.
DPF offers further benefits to increase performance, enhance security and facilitate moves and changes in the network.
For subnetted IP networks, DPF has an IP-cut-through facility that allows establishment of data-direct VCCs between IP workstations on different IP subnet VLANs. By enabling IP-cut-through and shortening the IP subnet mask in end-stations, the end-stations communicate directly with each other without involving an IP device. This significantly increases IP throughput in the network, reduces IP routing requirements, and isolates IP subnet broadcast traffic.
IP-cut-through can be enabled or disabled by an IP subnet or IP end-station. IP-cut-through can also be configured to allow cut-through in one direction but force a routed path in the reverse direction. This uni-directional cut-through can be used to force IP clients to go through an IP device for security but allow IP servers to "cut through" to the clients for maximum performance.
Since DPF automatically adjusts the forwarding domain of a VLAN based on traffic, it lets users move around the network without any changes to their configuration. This is especially useful for IP networks, because it eliminates the need for assigning new IP addresses when users move.
DPF is a bridging enhancement. All ports on the ASRT bridge environment must be the same type. VLANs can be configured for multiple IP subnets, multiple IPX networks, a single NetBIOS network, user-defined traffic types, and IP multicast groups.
You must statically configure VLAN ports in the following situations:
Devices such as printers, servers or devices on a port could lose connectivity because of low network utilization. To prevent aging-out of a port that defines a VLAN to such a device, configure the port statically; specify include when prompted to configure the VLAN on the port. For example:
IPX clients do not know their network numbers. This prevents a VLAN from learning the association between the network number and the port number. Specify include when prompted to configure the VLAN for a bridge port connected to IPX clients only.
IP Cut-Through enables communication between stations on different IP subnets. IP Cut-Through is applicable in subnetted IP networks only. If stations are on different IP nets, then communication cannot be established between them and a device must be used to forward traffic between those stations.
To use IP Cut-Through, the subnet mask in end-stations (typically just servers) should be shortened. That is, a 255.255.255.255 subnet mask is shortened to 255.255.255.0 to imply a 3-byte subnet and a 255.255.0.0 subnet mask implies a 2-byte subnet. Shortening the subnet mask will cause the end-station to ARP for the destination and establish communication to the destination (or intermediate LAN switch), maximizing network throughput. However, this configuration can produce the following side effects:
If these end-stations are ATM-attached, the number of ATM connections (data-direct VCCs) will also increase.
Therefore, the need for faster network throughput must be balanced against increased CPU utilization in the end-stations and increased VCC utilization in the ATM switches.
Answering Yes to the Enable IP-Cut-Through from this VLAN? question will allow forwarding of IP traffic from devices on this VLAN to devices on other VLANs that have IP-Cut-Through reception enabled.
Unlike other VLANs, IP Multicast VLANs can be automatically created and configured without user involvement. If auto-creation of IP Multicast VLANs is enabled, then the receipt of an IGMP Report frame (indicating a station's membership in an IP multicast group) causes an IP Multicast VLAN to be created for the group address indicated in the frame. Thus, IP Multicast groups can be configured on stations in the network without the need for VLAN configuration in the MSS bridge.
Auto-creation is enabled if an IP Multicast VLAN exists for the all IP hosts address of 224.0.0.1 and is enabled. If not already present, this VLAN is created and enabled during box initialization. It contains the initial port configuration, aging time, and MAC Address tracking status that will be applied to each new IP Multicast VLAN that is automatically created. To turn off auto-creation of IP Multicast VLANs, disable the VLAN for the 224.0.0.1 group address.
No IP Multicast VLANs can be auto-created or manually configured for the reserved multicast groups whose address is between 224.0.0.0 and 224.0.0.255, inclusive. This prevents potential problems in filtering frames necessary to several protocols that use these addresses.